Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/app/`(with-header)/activities/[id]/components/BookingSection.tsx:
- Around line 61-66: Remove the unnecessary setTimeout wrapper in
handleMonthChange inside BookingSection.tsx: call setYear(year) and
setMonth(month) directly (no delayed callback) since React 18+ batches state
updates; keep the useCallback for handleMonthChange but you can leave the
dependency array empty (setState setters are stable) or include setYear/setMonth
if you prefer explicit deps.
- Around line 50-54: The filter uses PromiseFulfilledResult<any> which triggers
no-explicit-any; replace the any with the actual fulfilled value type by
declaring or reusing the correct type for the responses (e.g., SideItem or the
API response type) and update the type guard on sideResults to (r): r is
PromiseFulfilledResult<TheRealType> => r.status === 'fulfilled' so flatMap((r)
=> r.value.data) has a concrete type; locate the sideResults variable and the
data shape used in BookingSection.tsx to pick the exact type (or import an
existing interface) and use that type in the PromiseFulfilledResult generic.

In `@src/app/`(with-header)/activities/[id]/components/Title.tsx:
- Around line 27-30: Extract the duplicated owner-check logic (currently using
useUserStore and computing currentUserId and isOwner in Title.tsx,
BookingSection.tsx, and ActivityDetailSkeleton.tsx) into a small reusable hook
named useIsOwner(userId) that returns a boolean; implement useIsOwner to read
currentUserId from useUserStore (same selector used today) and return
currentUserId != null && currentUserId === userId, then replace the inline logic
in Title.tsx, BookingSection.tsx, and ActivityDetailSkeleton.tsx to call
useIsOwner(userId) instead of duplicating the selector and comparison.

In `@src/app/`(with-header)/activities/[id]/loading.tsx:
- Around line 4-72: Extract the duplicated skeleton markup into a single shared
presentational component (e.g., ActivityDetailSkeleton or
SharedActivitySkeleton) and have both the server Loading() and the existing
ActivityDetailSkeleton.tsx consume it; move purely UI pieces (the grid,
placeholders, and repeated ReviewCardSkeleton usage) into the new shared
component and keep client-only bits like SkeletonBookingInterface or
ReviewCardSkeleton usage either inside a small client wrapper component or
passed as slots/props so Loading (a server component) can render the shared
layout without importing client-only modules directly; update Loading and
src/app/.../ActivityDetailSkeleton.tsx to import and render the new shared
component, preserving keys like ReviewCardSkeleton and SkeletonBookingInterface
by wrapping them in a client component if needed.
- Line 6: The outer container div that currently has the class 'animate-pulse'
is causing nested animation with the child skeleton components
(ReviewCardSkeleton and SkeletonBookingInterface); remove the 'animate-pulse'
class from the outer div (the div with className 'mx-auto max-w-1200 ...') so
that only the inner components control their own pulse animation, ensuring no
overlapping/duplicated animation occurs and keeping ReviewCardSkeleton and
SkeletonBookingInterface as the sole owners of their skeleton animation.

In `@src/app/`(with-header)/activities/[id]/page.tsx:
- Around line 54-78: Create a small client-side wrapper component (e.g.,
ActivityDetailClientLayout or BookingSectionWrapper) that determines current
user ownership and renders the outer grid with md:grid-cols-2 when the viewer is
the owner and md:grid-cols-3 otherwise; move the markup currently in page.tsx
(the div with mt-86 grid ... and its children including BookingSection,
LocationMap, ReviewSection) into that wrapper and use BookingSection (which may
return null) inside it so the wrapper can adjust the grid class based on
isOwner. Reference BookingSection and ActivityDetailSkeleton behavior as a model
for switching grid-cols depending on ownership; keep BookingSection
implementation unchanged and ensure page.tsx imports and uses the new client
wrapper instead of the static md:grid-cols-3 div.
- Around line 30-33: Change the catch parameter from any to unknown and add a
type guard (e.g., isNotFoundError(error: unknown): error is Error & { digest:
string }) that checks error instanceof Error and that error.digest ===
'NEXT_NOT_FOUND'; in the catch block use that guard to rethrow the
NEXT_NOT_FOUND error and otherwise throw the existing new Error('활동 상세 데이터 조회
실패') so you avoid using the any type while preserving the current behavior.

In `@src/app/`(with-header)/myactivity/hooks/useCreateActivityForm.ts:
- Around line 39-67: The current flow uploads bannerImageUrl and subImageUrls
via uploadImage before calling privateInstance.post('/addActivity'), which can
leave orphaned uploaded files if the POST fails; wrap the upload + POST sequence
in a try/catch and on any failure delete any already-uploaded images: track
uploaded URLs in bannerImageUrl and subImageUrls, and in the catch call your
storage deletion helper (e.g., deleteImage or an API endpoint you add) for each
uploaded URL, then rethrow or surface the error; update useCreateActivityForm to
perform uploads, attempt privateInstance.post('/addActivity', payload) inside
the same try, and cleanup uploaded images on catch to avoid orphaned resources.
- Around line 47-54: Replace the sequential for...of+await loop that uploads
each entry in subImage with a parallel Promise.all approach: map subImage to an
array of promises where each element returns uploadImage(img) if img is a File
or returns the img string otherwise, then await Promise.all on that array and
assign the resulting array to subImageUrls (or push the results) so uploads
happen concurrently; locate the logic in useCreateActivityForm where subImage,
uploadImage, and subImageUrls are referenced.

In `@src/app/api/editActivity/`[id]/route.ts:
- Line 40: The call to revalidateTag in the Route Handler uses the deprecated
single-argument form; update the invocation of revalidateTag(`activity-${id}`)
to the recommended two-argument form revalidateTag(`activity-${id}`, 'max') so
TypeScript errors are resolved and the tag is revalidated using SWR semantics;
locate the usage of revalidateTag in route.ts and change the call accordingly.

In `@src/app/api/reservations/`[id]/reviews/route.ts:
- Around line 42-44: Remove the unnecessary conditional guard and always call
revalidateTag using the required activityId from the ReviewResponse;
specifically, in the route handler replace the if-check around revalidateTag and
directly invoke revalidateTag(`activity-${response.data.activityId}`), relying
on the ReviewResponse.type (activityId: number) and the existing single-argument
revalidateTag usage.

---

Outside diff comments:
In `@src/components/DatePicker/DatePicker.tsx`:
- Around line 55-65: Remove the debug console.logs: delete the entire useEffect
that only logs availableDates, highlightDates, and viewDate (the useEffect
referencing availableDates and viewDate) and remove the top-level console.log in
the component body; ensure you do not rely on that effect for any side effects
and that any real effects include all needed deps (e.g., add highlightDates to
deps if you later reintroduce an effect) — search for the useEffect containing
availableDates.map and highlightDates.map and the standalone console.log at the
component's top level to locate and remove them.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/app/`(with-header)/activities/[id]/components/BookingSection.tsx:
- Line 60: The enabled condition includes redundant checks (!!year && !!month)
that are always truthy since year and month are initialized, so remove them and
change the enabled expression to only depend on activityId and isOwner (e.g.,
use activityId presence and !isOwner) in the same object where enabled is
defined (referencing enabled, activityId, year, month, isOwner to locate the
line).
- Line 27: The condition userId != null is redundant because the userId prop is
typed as number; update the isOwner calculation by removing that redundant guard
so it reads a single check comparing currentUserId and userId while still
guarding currentUserId (e.g., replace the expression in the isOwner constant
with a null-check only for currentUserId and direct equality to userId); target
the isOwner declaration in BookingSection.tsx and the userId prop usage to
implement this simplification.
- Around line 32-58: The code currently awaits currentResponse before starting
prev/next requests causing serial latency; change to start all three requests
concurrently by creating promises with privateInstance.get for the current month
and the two side months (using activityId and padMonth) before awaiting; then
await them together (e.g., via Promise.allSettled), ensure you check the current
month's promise result first and if it rejected rethrow the error to preserve
previous failure behavior, and finally collect fulfilled side responses
(filtering PromiseFulfilledResult for the two side promises) and merge their
data with the currentResponse.data.

---

Duplicate comments:
In `@src/app/`(with-header)/activities/[id]/components/BookingSection.tsx:
- Around line 63-68: The handler handleMonthChange currently wraps setYear and
setMonth in an unnecessary setTimeout; remove the setTimeout wrapper so the
function directly calls setYear(year) and setMonth(month). Keep it as a
useCallback and ensure the callback references the existing state setters
(setYear, setMonth) so the dependency array remains appropriate (they are stable
from useState).